hisilicon-osdrv-hi3520dv200: ship V2 MPP headers + libhdmi.a#2120
Merged
widgetii merged 1 commit intoMay 21, 2026
Merged
Conversation
Today the published hi3520dv200 toolchain ships hi3516cv100-era MPP
headers as a fallback (Makefile BUNDLE_SDK at line 131: if a board has
no files/include/, the cv100 set is copied in unconditionally for every
hisilicon board). That worked as a stopgap because the common subset
of struct layouts is stable across V1/V2, but it has two gaps for
hi3520dv200:
1. mpi_hdmi.h / hi_comm_hdmi.h are V2-era additions (cv100 has no
HDMI hardware), so HDMI bring-up via HI_MPI_HDMI_Open/SetAttr/
Start can't be compiled against the toolchain — consumers have to
vendor the headers themselves.
2. cv100 ships ISP/sensor/3A headers (mpi_isp.h, mpi_ae.h, etc.) that
are meaningless on the analog-input hi3520dv200 board — they're
dead weight and a source of misleading "cv100 SDK" assumptions.
Mirror the V2 hi3520dv200 header set from the openhisilicon kernel
include directory into files/include/. Once the toolchain rebuilds,
the cv100 fallback is skipped (the `! -d "$OSDRV_DIR/include"` guard
in BUNDLE_SDK now sees the new dir) and the SDK ships the V2-correct
set:
hi_comm_hdmi.h, mpi_hdmi.h — HDMI control API (new)
hi_jpeg_api.h + jpeg/libjpeg.h — JPEG decode/encode API (new)
mkp/mod_ext.h — vendor module extension (new)
hi_comm_*, mpi_*, hi*.h, hifb.h — V2 MPP base (replaces cv100)
Header diff cv100 -> V2:
removed (cv100 only): acodec.h, hi_ae_comm.h, hi_af_comm.h,
hi_awb_comm.h, hi_comm_3a.h, hi_comm_isp.h, hi_comm_sns.h,
hi_isp_debug.h, hi_pq_bin.h, hi_sns_ctrl.h, hi_vreg.h, mod_ext.h,
mpi_ae.h, mpi_af.h, mpi_awb.h, mpi_isp.h — all ISP/sensor/3A,
none of which apply to hi3520dv200 (no in-tree consumer compiles
against them for this board)
added (V2 only): hi_comm_hdmi.h, mpi_hdmi.h, hi_jpeg_api.h,
jconfig.h, jerror.h, jmorecfg.h, jpeglib.h, mkp/mod_ext.h
shared: 46 headers (the common V1/V2 MPP base)
Also drops libhdmi.a alongside the existing libmpi.so / libaec.so /
etc. in files/lib/. The HDMI control API (HI_MPI_HDMI_Init / Open /
GetAttr / SetAttr / Start) is NOT exported by libmpi.so on this SoC
(nm/strings come up empty) — vendor split it into a separate static
library that has to be linked into the consumer. Without this, VO_Enable
returns 0x0 but the HDMI module reports "do not Open" in /proc/umap/hdmi
and the monitor sees no signal.
Source provenance:
files/include/ <- openhisilicon kernel/include/hi3520dv200
(public mirror of vendor V2 MPP headers)
files/lib/libhdmi.a <- Hi3520D_SDK_V2.0.5.1/package/mpp/lib/libhdmi.a
(vendor static library, 19 KiB)
No in-tree package currently builds userspace against MPP headers for
hi3520dv200 (osdrv ships only kmod/lib/script; opensdk handles kernel
modules), so this change can't regress any existing build. Verified
the openhisilicon mirror's headers compile against the published
toolchain via the dvr_home demo (private hifb-demo repo) with VENC
all-channel bring-up and HDMI bring-up both succeeding.
Once this lands + the toolchain release rebuilds (delete the stale
toolchain.hisilicon-hi3520dv200.tgz asset, re-run toolchain.yml),
the next consumer to drive HDMI on this SoC can just `-lhdmi` like
they already `-lmpi` instead of vendoring the blob.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add board-specific MPP headers and the HDMI static library to the hi3520dv200 osdrv package so the published toolchain SDK ships them next to
libmpi.so. Today the board has nofiles/include/and theBUNDLE_SDKfallback (Makefile:131) copies the hi3516cv100 header set into every hisilicon toolchain — which works as a common-subset stopgap but has two real gaps for hi3520dv200:mpi_hdmi.h/hi_comm_hdmi.hare V2-era additions (cv100 has no HDMI hardware), so consumers that needHI_MPI_HDMI_Open/SetAttr/Startto bring HDMI out of "do not Open" state have to vendor the headers themselves. Symptom:HI_MPI_VO_Enablereturns 0x0,/proc/umap/voclaims DevEn=Y, but/proc/umap/hdmireportsHDMI driver do not Openand the monitor sees no signal.libmpi.soon this SoC (nm -D libmpi.so | grep HDMIreturns nothing); vendor split it into a separate static library that has to be linked into the consumer.ISP/sensor/3A headers from cv100 (
mpi_isp.h,mpi_ae.h, etc.) are also misleading on this analog-input DVR SoC and just dead weight in the SDK.What changes
Header diff cv100 → V2:
acodec.h,hi_ae_comm.h,hi_af_comm.h,hi_awb_comm.h,hi_comm_3a.h,hi_comm_isp.h,hi_comm_sns.h,hi_isp_debug.h,hi_pq_bin.h,hi_sns_ctrl.h,hi_vreg.h,mod_ext.h,mpi_ae.h,mpi_af.h,mpi_awb.h,mpi_isp.hhi_comm_hdmi.h,mpi_hdmi.hhi_jpeg_api.h,jconfig.h,jerror.h,jmorecfg.h,jpeglib.hmkp/mod_ext.hhi_comm_*/mpi_*/hi*.h/hifb.hOnce
BUNDLE_SDKsees the newfiles/include/, its! -d \"$OSDRV_DIR/include\"guard skips the cv100 fallback and the publishedtoolchain.hisilicon-hi3520dv200.tgzships the V2-correct headers +libhdmi.ainsdk/include/andsdk/lib/. Consumers then just-lhdmilike they already-lmpi.Provenance
files/include/content is a verbatim copy ofopenhisilicon's public mirror atkernel/include/hi3520dv200(the same source that's been the de-facto reference for V2 MPP headers in the community).files/lib/libhdmi.ais the vendor's static library fromHi3520D_SDK_V2.0.5.1/package/mpp/lib/libhdmi.a(the same SDK the existinglibmpi.so/libaec.so/ etc. infiles/lib/come from).Why now / no regressions
No in-tree package currently compiles userspace against MPP headers for hi3520dv200 —
hisilicon-osdrv-hi3520dv200itself ships only kmods/scripts/blobs, andhisilicon-opensdkhandles kernel modules. So this can't regress any existing build.Verified end-to-end against the openhisilicon V2 header set in a downstream dvr_home demo (private hifb-demo repo):
HI_MPI_VENC_CreateGroup/CreateChn/RegisterChnall return 0x0 on chns 0..3, and the HDMI bring-up sequence (Init→Open→GetAttr→SetAttrwithHI_HDMI_VIDEO_FMT_720P_60→Start) brings/proc/umap/hdmitoOpen=y Start=y EDID Parse Status: Okwith the monitor displaying 720P60.Test plan
make BOARD=hi3520dv200_litebuilds clean (no in-tree consumers of MPP userspace headers to break).BUNDLE_SDKpacks the newfiles/include/andfiles/lib/libhdmi.ainto the toolchain tarball — confirmed by walking the Makefile logic; thecp -a $OSDRV_DIR/*copies both subdirs and the cv100-fallback guard skips correctly.toolchain.hisilicon-hi3520dv200.tgzrelease asset and re-runtoolchain.yml(same pattern as the rebuild after glibc-compat: add static-link mmap shim (32-bit off_t for vendor V2 blobs) #2110); verify the new tarball shipssdk/include/mpi_hdmi.handsdk/lib/libhdmi.a.gcc ... -L\$(TOOLCHAIN)/sdk/lib -lmpi -lhdmiresolves allHI_MPI_HDMI_*symbols.Refs
🤖 Generated with Claude Code